ci: add typecheck gate to CI workflow - #280

@claude jesteś pewny, że build sam w sobie nie robi już typechecka? Jesteś w stanie to sprawdzić?

Sprawdziłem to empirycznie na czystym checkoucie main (lokalna gałąź, nic nie pushowane) — build nie robi typechecku, więc bramka nie jest redundantna.

Jak działają targety (z nx show project):

• build = vite build (transpilacja przez esbuild/Rollup — bez sprawdzania typów),
• typecheck = tsc --build --emitDeclarationOnly (prawdziwy tsc).

Test: wstrzyknąłem czysty błąd typu (nie składniowy) do packages/utils/src/lib/addPrefix.ts:

const _typeErrorProbe: number = "this is a string not a number"

nx run @leancodepl/utils:build:

[vite:dts] ... src/lib/addPrefix.ts:19:9 - error TS2322: Type 'string' is not assignable to type 'number'.
✓ built in 1.48s
NX   Successfully ran target build ...   (exit 0)

Czyli vite-plugin-dts (v4.5.4, skonfigurowany z tsconfigPath: tsconfig.lib.json) wypisuje diagnostykę TS jako log, ale build i tak kończy się sukcesem (exit 0) i emituje dist/. Domyślnie nie przerywa builda na błędach typów.

nx run @leancodepl/utils:typecheck:

src/lib/addPrefix.ts(19,9): error TS2322: Type 'string' is not assignable to type 'number'.
NX   Running target typecheck ... failed   (exit 1)

typecheck łapie błąd i kończy się niezerowym kodem.

Wniosek: build transpiluje/emituje nawet przy błędach typów (tylko je loguje), więc osobna bramka typecheck realnie dokłada pokrycie — szczególnie dla błędów w ścieżkach nieuruchamianych przez testy oraz w plikach spec, które build w ogóle pomija (tsconfig.lib.json wyklucza *.spec.*/*.test.*). PR ma sens, można mergować.

Zmiana testowa była tylko lokalna i została cofnięta.